Traditional software applications that rely on persistent state (i.e., state information that is saved across multiple program executions) store their data in volatile memory such as DRAM for fast access and periodically persist the data to a non-volatile storage device such as a magnetic hard disk, solid-state disk, etc. via a block-based interface. This model of persistence is known as block-based persistence (BlP). With BlP, the data structures maintained in volatile memory generally need to be serialized when persisting the data to non-volatile storage and de-serialized when reconstructing the data in volatile memory during an application restart or crash recovery. These serialization and de-serialization processes can be time-consuming, computationally intensive, and error prone.
Non-volatile byte-addressable memory (NVM) is an emerging memory technology that offers fast, fine grained access to data in a manner similar to DRAM, but is non-volatile in nature like conventional block-based storage. Examples of NVM technologies that are currently available or expected to be available in the near future include phase change memory (PCM), memristors, spin-torque transfer, and 3D XPoint. The unique characteristics of NVM enable an alternative model of persistence, known as byte-based persistence (ByP), in which an application can directly access (via, e.g., memory load/store instructions) a single version of its data in NVM that remains available after application termination. Thus, upon a restart or crash recovery, the application can simply continue accessing its data from NVM, without requiring an expensive reload and de-serialization of data structures from a block-based storage device.
One hurdle to the widespread adoption of NVM involves converting existing (i.e., legacy) software applications from the BlP model to the ByP model. The first step in this conversion is identifying which data structures in a legacy BlP application should be made persistent (e.g., placed in NVM) in the converted ByP application. However, this identification is not easy to do. One known approach is for the application's developer to manually review the codebase of the legacy BlP application, understand how each data structure in the application is used, and determine whether it semantically represents a data structure that should be maintained across multiple program executions or not. But, while this manual approach may be feasible for very small-scale conversion projects, it is not practical for medium to large-scale conversion projects due to the amount of developer time and effort that would be required.